Sprint 回顧 在 Sprint 評審之後 和下一個 Sprint 計劃之前進行。對於一個月的 Sprint來說,這最多是三個小時的會議。回顧會議基本上是一個“改進”會議,目的是尋找方法和手段來識別潛在的陷阱、過去的錯誤,並尋找新的方法來避免這些錯誤,所有的人—— 產品負責人、 Scrum Master、開發團隊成員都會參加。 ,並可選擇與利益相關者。
Sprint 回顧會議的時長
衝刺回顧會議時長的經驗法則是每週衝刺持續時間通常不超過 45 分鐘。下表說明了此規則:
一般格式略有不同,但通常我們會這樣做:
- 我們可以將會議的時間框與 Sprint 持續時間成正比。
- 參與者:產品負責人、整個團隊和我自己。
- 只要我們可以進行不受干擾的討論,我們就會搬到一個封閉的房間或舒適的沙發角落。
- 有人被指定為秘書。
- Scrum master 顯示 sprint backlog,並在團隊的幫助下總結 sprint。重要事件和決定等
- 我們做“巡迴演出”。每個人都有機會暢所欲言,不會被打斷,Sprint 中什麼進展順利?Sprint 出了什麼問題?我們在 Sprint 中學到了什麼?在下一個 sprint 中我們應該做些什麼不同的事情?
- 我們查看估計速度與實際速度。如果有很大差異,我們嘗試分析原因。
- 當時間快到時,Scrum master 會嘗試總結關於我們在下一個 sprint 中可以做得更好的具體建議。
我們的回顧通常不太結構化。但是,基本主題始終是相同的:“我們在下一個 sprint 中可以做得更好嗎?”
關於回顧性問題的詳細信息
1. Sprint 中有哪些進展順利?
可以提出的可能的問題,通過問自己什麼是好的來承認已經發生的所有好事來理解迭代成功背後的原因。
- 是什麼促使我們這樣做?
- 我們做了什麼不同的事情來讓它成功?
- 哪些培訓、技能或知識促成了這種差異?
- 你的哪個優點使它發生?
- 你的團隊的哪些優勢使它成為現實?
- 幫助你完成它的團隊成員的貢獻是什麼?
- 我們是如何實現的?
2. Sprint 出了什麼問題?
雖然本節中的問題不應該被用來評估個人的表現或懲罰,但應該收集信息,並確定在即將到來的 Sprint 中解決它的方法。哪裡比進展不順利的地方更好地尋求改進?事實上,這個問題揭示了團隊目前面臨的困難、問題和不滿。
- 它是怎麼出錯的?
- 你做錯了什麼?
- 有多少人要為這個錯誤負責?
- 你在哪裡意識到這樣做會出錯?
- 您是否理解錯誤並因此執行錯誤?
- 你理解對了,但還是出錯了?
- 我們在哪些方面做得很好?
3. 我們在 Sprint 中學到了什麼?
從這個 Sprint 中學到了什麼?這些問題有助於確定什麼是對的,什麼是錯的。它鼓勵我們審視我們對工作方式的了解。一些例子可能是:
- 這個 sprint 是如何執行的?
- 在這個 sprint 中哪裡出錯了?
- 什麼時候出錯了?
- 它是怎麼出錯的?
- 哪些技術有用?
- 哪些技術沒用?
- 在這個 sprint 中,什麼進展順利?
- 在這個 sprint 中發生了什麼不順利的事情?
- 本次 Sprint 中的哪些學習可以為即將到來的 Sprint 教育我們?
4. 在下一個 Sprint 中我們應該做些什麼不同的事情?
本節主要側重於從過去的成功、失敗和學習中確定可能的糾正措施。
- 如何利用個人的力量來解決問題?
- 應該經常做些什麼來防止問題再次出現?
- 在您有足夠的帶寬和能力的情況下,哪些行動必須立即實施?
- 確定要更改的 1 件事並解釋如何更改它?
- 什麼策略可以完成這項工作?
糾正措施
- 在即將到來的 Sprint 中你會做什麼來完成這個動作?
- 你將如何做才能讓它成功?
- 在 Sprint 期間你什麼時候做?
- 您需要幫助來完成此操作嗎?
- 您需要哪些額外支持?
- 你怎麼讓我知道你完成了它?
- 在 Sprint 期間完成此任務後,您接下來會做什麼?
回顧中經常出現的問題
“我們應該花更多時間將故事分解為子項目和任務”
“外來干擾太多”
“我們過度投入,只完成了一半的工作”
“我們的辦公環境太吵太亂”
概括
Scrum 回顧會議可以被認為是“經驗教訓”會議。正確的回顧性問題允許團隊思考,同時為每個團隊成員提供所有權,從而使其真正 敏捷。
根據場景使用上面給出的問題,並激勵您的團隊和您自己在未來的 Sprint 中表現出改進。雖然這些示例問題是指示性的,但您可以根據自己的要求進行自定義。